[小ネタ]S3 ライフサイクルや CloudWatch Logs 保持期限設定により行われるオブジェクトの削除は SCP の影響を受けない

Amazon S3 のライフサイクルポリシーや Amazon CloudWatch Logs の保持期限設定を利用したオブジェクト削除は SCP の影響を受けません！

#Amazon S3

#CloudWatch Logs

#AWS Organizations

#AWS

とーち

2023.04.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

1. はじめに

お疲れさまです。とーちです。
AWS Organizations、良いですよね。その中でも Service Control Policies (SCP)は組織のアカウント全体に統制をかけることができる便利な機能です。
ところで、みなさんは Amazon S3 のライフサイクルポリシーや Amazon CloudWatch Logs の保持期限設定を利用したオブジェクト削除が SCP の影響を受けるか答えられますか？例えば SCP で"s3:DeleteObject"を禁止しているとき、S3 ライフサイクルポリシーによる削除が動くとどうなるでしょうか？

私は知らなかったので、この記事では実際に試した結果を踏まえてお伝えしようと思います。

2. とりあえず結論

S3 のライフサイクルでの削除等のアクションは SCP の影響を受けずに実行される
CloudwatchLogs の保持期限超過による削除も SCP の影響を受けずに実行される

3. 準備

上記の通り、SCP の影響は受けないのですが、実際に試して確認してみようと思います。

3.1. S3 ライフサイクルポリシーの設定

まずは SCP を適用する予定の AWS Organizations のメンバーアカウントにて、適当な S3 バケットを作成します。

S3 バケットにライフサイクルポリシーを設定します。今回は１日経ったらオブジェクトが削除されるという設定にします（画面の表記だと分かりづらいのですが、「バケットのバージョニング」設定が有効でないバケットでは、オブジェクトが有効期限切れになると完全に削除されます）。

最後に S3 バケットに適当なファイルをアップロードしておきます。

これにより、指定された期間後にオブジェクトが自動的に削除されるはずです。

3.2. CloudWatch Logs 保持期限の設定

上記 S3 と同様に SCP を適用した AWS アカウントにて、CloudWatch Logs の適当なロググループに保持期限を設定します。

ロググループ内にログストリームがあることを確認しておきます。

これにより、指定された期間後にログデータが自動的に削除されるようになります。

3.3. SCP の適用

AWS Organizations の管理アカウントにて適当な OU を用意して、その中にアカウントを所属させます。

次にこの OU に対して以下のような SCP を設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "s3:PutLifecycleConfiguration",
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "logs:DeleteLogGroup",
        "logs:DeleteLogStream",
        "logs:DeleteRetentionPolicy",
        "logs:PutRetentionPolicy"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

これにより、OU に所属した AWS アカウント内では S3 内オブジェクト削除や、CloudwatchLogs のログストリーム削除等のアクションが制限されます。
上記の SCP では、保持期限設定の変更や S3 ライフサイクルポリシーの変更なども禁止しています。これらも禁止対象とすることで、ライフサイクル設定を使って間接的に S3 内のオブジェクトを削除する等の抜け道を防ぐことができます。
また上記の SCP はテスト用なので、全てのリソース、プリンシパルを対象に Deny していますが、実際の運用では特定のリソースに絞ったり、Condition 等で特定の IAM ロールのみ Deny の対象から除外するなどしたほうが良いと思います。

3.4. 事前動作確認

事前に SCP がちゃんと適用されていることを確認するために上記で作成した各オブジェクトを削除してみます。削除は AdministratorAccess のマネージドポリシーを付与した IAM ロールを使って確認していきます。

S3 オブジェクトを削除してみます。

ちゃんと削除操作が拒否されているのがわかります。

続いて CloudwatchLogs のログストリームを削除してみます。

こちらも正常に削除操作が拒否されました

ちゃんと SCP が適用されているのがわかったのでこのまま S3 ライフサイクルや CloudwatchLogs 保持期限により削除されるまで待ってみます。
ちなみに CloudwatchLogs の保持期限による削除は保持期限に達してから、最大７２時間かかりますし、S3 のライフサイクルも削除されるまで下記記事が示す通り時間がかかります。気長に待ちましょう。

S3 ライフサイクルルールの動きを理解してみた | DevelopersIO

4. 実行結果

しばらくしてから S3 と CloudwatchLogs をそれぞれ確認してみました。
まずは S3、以下の通りオブジェクトが削除されています。

続いて CloudwatchLogs、こちらもログストリームが削除されていました。

実行結果から、S3 ライフサイクルポリシーや CloudWatch Logs の保持期限設定によるオブジェクトおよびログデータの削除が、SCP の影響を受けずに実行されたことが確認できました。

5. その他注意点

ちなみにS3 のユーザーガイドに記載があるのですが、S3 ライフサイクルによるアクションは「内部のエンドポイント」を使用するため CloudTrail の「バケット内のオブジェクトのログ記録」を有効にしていても記録されません。
Cloudwatchlogs の保持期限による削除についてもドキュメント上の記載箇所は見つけられませんでしたが、CloudTrail に記録はされていませんでした。
上記の動きは頭の片隅においておくといいかもしれません。